fix: Add structured 404 responses for ResourceNotFoundException [MDD-78]

Summary

Adds explicit @ExceptionHandler for ResourceNotFoundException in the REST exception handler and parallel handling in the GraphQL exception handler, so that invalid username lookups (and all other resource-not-found scenarios) return a structured {"message": "Resource not found"} JSON body instead of a raw, empty 404.

Changes:

• CustomizeExceptionHandler: New handler method returning HttpStatus.NOT_FOUND with a JSON body, following the existing InvalidAuthenticationException pattern.
• GraphQLCustomizeExceptionHandler: New else if branch returning a TypedGraphQLError with ErrorType.NOT_FOUND, inserted before the default handler fallback.
• ProfileApiTest: Three new test cases covering GET profile, POST follow, and DELETE unfollow with nonexistent usernames.

This fix applies application-wide to all endpoints that throw ResourceNotFoundException (ProfileApi, ArticleApi, CommentsApi, ArticleFavoriteApi, etc.).

Updates since last revision

• Removed unused import static org.mockito.ArgumentMatchers.any from ProfileApiTest.java.
• Verified locally by running the app and curling all three profile endpoints with nonexistent usernames. Results confirm that the @ExceptionHandler takes precedence over the @ResponseStatus annotation on the exception class, and the structured JSON body is returned correctly:
  • GET /profiles/nonexistent_user → 404 {"message":"Resource not found"}
  • POST /profiles/nonexistent_user/follow (with auth) → 404 {"message":"Resource not found"}
  • DELETE /profiles/nonexistent_user/follow (with auth) → 404 {"message":"Resource not found"}

Review & Testing Checklist for Human

• No GraphQL test coverage: The GraphQLCustomizeExceptionHandler change has no corresponding test. Consider whether a GraphQL-layer test should be added for the NOT_FOUND path to guard against regressions.
• @ResponseStatus vs @ExceptionHandler precedence: ResourceNotFoundException has @ResponseStatus(HttpStatus.NOT_FOUND) on the class. Local testing confirmed the @ExceptionHandler wins and the structured body is returned, but verify this holds in your deployment environment as well since Spring Boot version or configuration differences could affect precedence.
• Manual test plan: Start the app (./gradlew bootRun), register a user, then:

  # GET nonexistent profile (no auth needed)
  curl -s http://localhost:8080/profiles/nonexistent_user
  # POST follow nonexistent user (auth required)
  curl -s -X POST http://localhost:8080/profiles/nonexistent_user/follow -H "Authorization: Token <token>"
  # DELETE unfollow nonexistent user (auth required)
  curl -s -X DELETE http://localhost:8080/profiles/nonexistent_user/follow -H "Authorization: Token <token>"

  Confirm all return HTTP 404 with body {"message": "Resource not found"}.

Notes

• The error message is intentionally generic ("Resource not found") to stay consistent across all resource types that use this exception.
• All CI checks (build, Snyk security/license) pass.
• Requested by: @milind-cognition
• Link to Devin run